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1 Motivation 

Find the type error in the following Haskell expression: 

if null xs then tail xs else xs 

You can’t, of course: this program is obviously nonsense unless you’re a type- 
checker. The trouble is that only certain computations make sense if the null xs 
test is True, whilst others make sense if it is False. However, as far as the type 
system is concerned, the type of the then branch is the type of the else branch is 
the type of the entire conditional. Statically, the test is irrelevant. Which is odd, 
because if the test really were irrelevant, we wouldn’t do it. Of course, tail [] 
doesn’t go wrong—well-typed programs don’t go wrong—so we’d better pick a 
different word for the way they do go. 

Abstraction and application, tupling and projection: these provide the ‘soft¬ 
ware engineering’ superstructure for programs, and our familiar type systems 
ensure that these operations are used compatibly. However, sooner or later, most 
programs inspect data and make a choice—at that point our familiar type sys¬ 
tems fall silent. They simply can’t talk about specific data. All this time, we 
thought our programming was strongly typed, when it was just our software en¬ 
gineering. In order to do better, we need a static language capable of expressing 
the significance of particular values in legitimizing some computations rather 
than others. We should not give up on programming. 

James McKinna and I designed Epigram [27,26] to support a way of pro¬ 
gramming which builds more of the intended meaning of functions and data into 
their types. Its style draws heavily from the Alf system [13,21]; its substance 
from my to Randy Pollack’s Lego system [20,23] Epigram is in its infancy and 
its implementation is somewhat primitive. We certainly haven’t got everything 
right, nor have we yet implemented the whole design. We hope we’ve got some¬ 
thing right. In these notes, I hope to demonstrate that such nonsense as we have 
seen above is not inevitable in real life, and that the extra articulacy which de¬ 
pendent types offer is both useful and usable. In doing so, I seek to stretch your 
imaginations towards what programming can be if we choose to make it so. 

1.1 What are Dependent Types? 

Dependent type systems, invented by Per Martin-Lof [22] generalize the usual 
function types S —► T to dependent function types \/x: S => T, where T may 


mention—hence depend on— x. We still write S —> T when T doesn’t depend 
on x. For example, matrix multiplication may be typed 1 

mult : Vi,j,k: Nat =>- Matrix ij —> Matrix j k — ► Matrix i k 

Datatypes like Matrix i j may depend on values fixing some particular prop¬ 
erty of their elements—a natural number indicating size is but one example. A 
function can specialize its return type to suit each argument. The typing rules 
for abstraction and application show how: 

x:S \~ t : T f:Vx:S^T s:S 

Xx =>t : Vx:S =>T fs : [s/x\T 

Correspondingly, mult 2 31: Matrix 2 3 —> Matrix 3 1 —> Matrix 2 1 
is the specialized multiplier for matrices of the given sizes. 

We’re used to universal quantification expressing polymorphism , but the 
quantification is usually over types. Now we can quantify over all values, and 
these include the types, which are values in *. Our V captures many forms of 
abstraction uniformly. We can also see Vs:S' =>T as a logical formula and its in¬ 
habitants as a function which computes a proof of [ s/x]T given a particular value 
s in S. It’s this correspondence between programs and proofs, the Curry-Howard 
Isomorphism, with the slogan ‘Propositions-as-Types’, which makes dependent 
type systems particularly suitable for representing computational logics. 

However, if you want to check dependent types, be careful! Look again at 
the application rule; watch s hopping over the copula, 2 from the term side in 
the argument hypothesis (eg., our specific dimensions) to the type side in the 
conclusion (eg., our specific matrix types). With expressions in types, we must 
think again about when types are equal. Good old syntactic equality won’t do: 
mult (1+1) should have the same type as mult 2, so Matrix (1+1) 1 should be 
the same type as Matrix 2 1! If we want computation to preserve types, we need 
at least to identify types with the same normal forms. Typechecking requires 
the evaluation of previously typechecked expressions—the phase distinction is 
still there, but it’s slipperier. 

What I like about dependent types is their precise language of data struc¬ 
tures. In Haskell, we could define a sequence of types for lists of fixed lengths 

data ListO x = Nil 

data Listl x = ConsO x (ListO x) 

data List2 x = Consl x (Listl x) 

but we’d have to stop sooner or later, and we’d have difficulty abstracting over 
either the whole collection, or specific subcollections like lists of even length. In 

1 We may write \/x:X;y:Y => T for Mx : X =>My.Y => T and Mxi , X2 : X =>■ T for 

Wxi : X: xg : X =g T. We may drop the type annotation where inferrable. 

2 By copula, I mean the *:’ which in these notes is used to link a term to its typing: 
Haskell uses and the bold use the set-theoretic +’. 





Epigram, we can express the lot in one go, giving us the family of vector types 
with indices from Nat representing length. Nat is just an ordinary datatype. 

data f-Tj— - where (- mT^) : (— w ^ 

- ^Nat : -kJ - ^zero : Naty ^sucn : Naty 

data ( n w^ 3t ’ v ^ where ( —tt— r -■, - 

- y Vec nX : * J - \^vml : Vec zero A J 

x : X ; xs : Vec n X 
vcons x xs : Vec (sue n) X 

Inductive families [15], like Vec, are collections of datatypes, defined mutually 
and systematically, indexed by other data. Now we can use the dependent func¬ 
tion space to give the ‘tail’ function a type which prevents criminal behaviour: 

vtail : Vn : Nat =>■ \/X :* =£> Vec (sue n) X ->■ Vec n X 

For no n is vtail n X vnil well typed. Indexed types state properties of their 
data which functions can rely on. They are the building blocks of Epigram pro¬ 
gramming. Our Matrix i j can just be defined as a vector of columns, say: 

let ( r ° W ' S i c °l s ■ N a t — \ ]V[ a t r i x rows co i s =*> \/ec cols (Vec rows Nat) 
— y Matrix rows cols : * J v ' 

Already in Haskell, there are hooks available to crooks who want more control 
over data. One can exploit non-uniform polymorphism to enforce some kinds of 
structural invariant [31], like this 

data Rect col x = Columns [col] | Longer (Rect (col, x)) 
type Rectangular = Rect () 

although this type merely enforces rectangularity, rather than a specific size. 
One can also collect into a Vec type class those functors which generate vector 
structures [24]. Matrix multiplication then acquires a type like 

mult :: (Vec f,Vec g,Vec h)=> f (g Int) -> g (h Int) -> f (h Int) 

Programming with these ‘fake’ dependent types is an entertaining challenge, 
but let’s be clear: these techniques are cleverly dreadful, rather than dreadfully 
clever. Hideously complex dependent types certainly exist, but they express basic 
properties like size in a straightforward way—why should the length of a list be 
anything less ordinary than a number ? In Epigram, it doesn’t matter whether 
the size of a matrix is statically determined or dynamically supplied—the size 
invariants are enforced, maintained and exploited, regardless of phase. 










1.2 What is Epigram? 


Epigram is a dependently typed functional programming language. On the sur¬ 
face, the system is an integrated editor-typechecker-interpreter for the language, 
owing a debt to the Alf [13,21] and Agda [12] family of proof editors. Under¬ 
neath, Epigram has a tactic-driven proof engine, like those of Coq [11] and 
Epigram’s immediate ancestor, the ‘Oleg’ variant of Lego [20,23]. The latter has 
proof tactics which mimic Alf’s pattern matching style of proof in a more spar¬ 
tan type theory (Luo’s UTT [19]); James McKinna and I designed Epigram [27] 
as a ‘high-level programming’ interface to this technology. An Epigram program 
is really a tree of proof tactics which drive the underlying construction in UTT. 

But this doesn’t answer the wider cultural question of what Epigram is. How 
it does it relate to functional languages like SML [29] and Haskell [32]? How does 
it relate to previous dependently typed languages like DML [39] and Cayenne [4]? 
How does it relate pragmatically to more conventional ways of working in type 
theory in the systems mentioned above? What’s new? 

I’ll return to these questions at the end of these notes, when I’ve established 
more of the basis for a technical comparison, but I can say this much now: DML 
refines the ML type system with numerical indexing, but the programs remain 
the same—erase the indices and you have an ML program; Cayenne programs 
are LazyML programs with a more generous type system, including programs 
at the type level, but severely restricted support for inductive families. Epigram 
is not an attempt to strap a more powerful type system to standard functional 
programming constructs—it’s rather an attempt to rethink what programming 
can become, given such a type system. 

Dependent types can make explicit reference to programs and data. They 
can talk about programming in a way that simple types can’t. In particular, an 
induction principle is a dependent type. We learned this one as children: 

Natlnd : VP: Nat ^ 

P zero — * (Vn: Nat ^-Pn-tP (sue n)) ~+ 

Vn:Nat ^Pn 

It gives rise to a proof technique—to give a proof of a more general proposition 
P n, give proofs that P holds for more specific patterns which n can take. Now 
cross out ‘proof’ and write ‘program’. The induction principle for Nat specifies 
a particular strategy of case analysis and recursion, and Epigram can read it as 
such. Moreover, we can readily execute ‘proofs’ by induction, recursively applying 
the step program to the base value, to build a proof for any specific n: 

Natlnd P mz ms zero mz 

Natlnd P mz ms (sue n) ms n (Natlnd P mz ms n) 

Usually, functional languages have hard-wired constructs for constructor case 
analysis and general recursion; Epigram supports programming with any match¬ 
ing and recursion which you can specify as an induction principle and implement 
as a function. Epigram also supports a first-order method of implementing new 
induction principles—they too arise from inductive families. 


It may surprise (if not comfort) functional programmers to learn that de¬ 
pendency typed programming seems odd to type theorists too. Type theory is 
usually seen either as the integration of ‘ordinary’ programming with a logical 
superstructure, or as a constructive logic which permits programs to be quietly 
extracted from proofs. Neither of these approaches really exploits dependent 
types in the programs and data themselves. At time of writing, neither Agda 
nor Coq offers substantial support for the kind of data structures and programs 
we shall develop in these notes, even though Alf and ‘Oleg’ did! 

There is a tendency to see programming as a fixed notion, essentially untyped. 

In this view, we make sense of and organise programs by assigning types to them, 
the way a biologist classifies species, and in order to classify more the exotic 
creatures, like printf or the zipWith family, one requires more exotic types. 
This conception fails to engage with the full potential of types to make a positive 
contribution to program construction. Given what types can now express, let us 
open our minds afresh to the design of programming language constructs, and 
of programming tools and of the programs we choose to write anyway. 

1.3 Overview of the Remaining Sections 

2 Warm Up; Add Up tries to give an impression of Epigram’s interactive 

style programming and the style of the programs via very simple examples— 
addition and the Fibonacci function. I expose the role of dependent types 
behind the scenes, even in simply typed programming. 

3 Vectors and Finite Sets introduces some very basic datatype families and 

operations—I explore Vec and also the family Fin of finite enumeration types, 
which can be used to index vectors. I show how case analysis for dependent 
types can be more powerful and more subtle than its simply typed counter¬ 
part. 

4 Representing Syntax illustrates the use of dependent types to enforce key 

invariants in expression syntax—in particular, the A-calculus. I begin with 
untyped de Bruijn terms after the manner of Bird and Paterson [9] and end 
with simply typed de Bruijn terms in the manner of Altenkirch and Reus [2]. 3 
On the way, I’ll examine some pragmatic issues in data structure design. 

5 Is Looking Seeing? homes in on the crux of dependently typed programming— 

evidence. Programs over indexed datatypes may enforce invariants, but how 
do we establish them? This section explores our approach to data analy¬ 
sis [27], expressing inspection as a form of induction and deriving induction 
principles for old types by defining new families. 

6 Well Typed Programs which Don’t Go Wrong shows the development 

of two larger examples—a typechecker for simply typed A-calculus which 
yields a typed version of its input or an informative diagnostic, and a tagless 
and total evaluator for the well typed terms so computed. 

7 Epilogue reflects on the state of Epigram and its future in relation to what’s 

happening more widely in type theory and functional programming. 


As I’m fond of pointing out, these papers were published almost simultaneously and 
have only one reference in common. I find that shocking! 



I’ve dropped from these notes a more formal introduction to type theory: 
which introductory functional programming text explains how the typechecker 
works within the first forty pages? A precise understanding of type theory isn’t 
necessary to engage with the ideas, get hold of the basics and start programming. 
I’ll deal with technicalities as and when we encounter them. If you do feel the 
need to delve deeper into the background, there’s plenty of useful literature out 
there—the next subsection gives a small selection. 

1.4 Some Useful Reading 

Scholars of functional programming and of type theory should rejoice that they 
now share much of the same ground. It would be terribly unfortunate for the two 
communities each to fail to appreciate the potential contribution of the other, 
through cultural ignorance. We must all complain less and read more! 

For a formal presentation of the Epigram language, see ‘ The view from the 
left’ [27] For a deeper exploration of its underlying type theory—see ‘ Computa¬ 
tion and Reasoning: A Type Theory for Computer Science’ [19] by Zhaohui Luo. 
User documentation, examples and solutions to exercises are available online [26]. 

Much of the impetus for Epigram comes from proof assistants. Proof and 
programming are similar activities, but the tools have a different feel. I can 
recommend ‘ Coq’Art’ [7] by Yves Bertot and Pierre Casteran as an excellent 
tutorial for this way of working, and for the Coq system in particular. The 
tactics of a theorem prover animate the rules of its underlying type theory, so 
this book also serves as a good practical introduction to the more formal aspects. 

The seminal textbook on type theory as a programming language is ‘ Program¬ 
ming in Martin-Ldf’s type theory: an introduction’’ [35] by Bengt Nordstrom, 
Kent Petersson and Jan Smith. It is now fifteen years old and readily available 
electronically, so there’s no excuse to consider type theory a closed book. 

Type theorists should get reading too! Modern functional programming uses 
richer type systems to express more of the structure of data and capture more 
patterns of computation. I learned a great deal from ‘ Algebra of Programming ’ 
by Richard Bird and Oege de Moor [8]. It’s a splendid and eye-opening introduc¬ 
tion to a more categorical and calculational style of correct program construction. 
1 Purely Functional Data Structures’ by Chris Okasaki [30] is a delightful com¬ 
pendium of data structures and algorithms, clearly showing the advantages of 
fitting datatypes more closely to algorithms. 

The literature on overloading, generic programming, monads, arrows, higher- 
order polymorphism is too rich to enumerate, but it raises important issues which 
type theorists must address if we want to make a useful contribution to functional 
programming in practice. I’d advise hungry readers to start with this very series 
of Advanced Functional Programming lecture notes. 

1.5 For Those of you Watching in Black & White 

Before we start in earnest, let’s establish typographical conventions and relate 
the system’s display with these notes. Epigram’s syntax is two-dimensional: the 



buffer contains a document with a rectangular region selected—highlighted with 
a bright background. A document is a vertical sequence of lines; a line is a 
horizontal sequence of boxes; a box is either a character, or a bracket containing 
a document. A bracket is either a 
( ! 

group, ! ■ • ■ ! , which has the usual functions of parenthesis, or a 

! ) 

[ ! 

shed, ! • • • ! , where you can tinker with text as you please. An Epigram 

! ] 

line may thus occupy more than one ascii line. If a bracket is opened on a 
physical line, it must either be closed on that line or suspended with a !, then 
resumed on the next physical line with another !. I hasten to add that the 
Epigram editor does all of this box-drawing for you. You can fit two Epigram 
lines onto one physical line by separating them with ;, and split one Epigram 
line into two physical lines by prefixing the second with % 

The Epigram document is a syntax tree in which leaves may be sheds—their 
contents are monochrome and belong to you. You can edit any shed without 
Epigram spying on you, but the rest of the document gets elaborated —managed, 
typechecked, translated to UTT, typeset, coloured in and generally abused by 
the system. In particular, Epigram colours recognized identifiers. There is only 
one namespace—this colour is just for show. If you can’t see the colours in your 
copy of these notes, don’t worry: I’ve adopted font and case conventions instead. 


Blue 

sans serif, uppercase initial 

type constructor 

red 

sans serif, lowercase initial 

data constructor 

green 

serif, boldface 

defined variable 

purple 

serif, italic 

abstracted variable 

black 

serif, underlined 

reserved word 


These conventions began in my handwritten slides—the colour choices are 
more or less an accident of the pens available, but they seem to have stuck. 
Epigram also has a convention for background colour, indicating the elaboration 
status of a block of source code. 

white (light green when selected) indicates successful elaboration 
yellow indicates that Epigram cannot yet see why a piece of code is good 
brown indicates that Epigram can see why a piece of code is bad 

Yellow backgrounds come about when typing constraints cannot yet be solved, 
but it’s still possible for the variables they involve to become more instantiated, 
allowing for a solution in the future. 

There are some pieces of ASCII syntax which I cannot bring myself to uglify 
in E-T^X. I give here the translation table for tokens and for the extensible 
delimiters of two-dimensional syntax: 




* V 

A 

- 

A 

=► 

<- 

(7 



* all 

lam 

-> 

/\ 

= > 

< = 

( ! 

! ) 

! 

! 1 

— 


Moreover, to save space here, I adopt an end-of-line style with braces {}, 
where the system puts them at the beginning. 

At the top level, the document is a vertical sequence of declarations delin¬ 
eated by rules. A rule is a sequence of at least three-. The initial document 

has just one declaration, consisting of a shed, waiting for you to start work. 
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2 Warm Up; Add Up 

Let’s examine the new technology in the context of a simple and familiar prob¬ 
lem: adding natural numbers. We have seen this Epigram definition: 4 

data ( where ( -rr--} ; (— n • ^ 

- \^Nat : *J - \^zero : Naty ysucn : Naty 

We can equally well define the natural numbers in Epigram as follows: 

data Nat : * where zero : Nat ; sue : Nat —► Nat 

In Haskell, we would write ‘data Nat = Zero | Sue Nat’. 

The ‘two-dimensional’ version is a first-order presentation in the style of 
natural deduction rules 5 [34]. Above the line go hypotheses typing the arguments; 
below, the conclusion typing a template for a value. The declarations ‘zero is a 
Nat; if n is a Nat, then so is sue n’ tell us what Nats look like. We get the actual 
types of zero and sue implicitly, by discharging the hypotheses. 

4 Unary numbers are not an essential design feature; rest assured that primitive binary 
numbers will be provided eventually [10]. 

5 Isn’t this a big step backwards for brevity? Or does Haskell’s brevity depend on 
some implicit presumptions about what datatypes can possibly be? 



















We may similarly declare our function in the natural deduction style: 


let 


x, y : Nat 


plus x y : Nat 


This signals our intention to define a function called plus which takes two 
natural numbers and returns a natural number. The machine responds 


Plus xy |[] 


by way of asking ‘So plus has two arguments, x and y. What should it do with 
them?’. Our type signature has become a programming problem to be solved 
interactively. The machine supplies a left-hand side, consisting of a function 
symbol applied to patterns, binding pattern variables —initially, the left- 
hand side looks just like the typical application of plus which we declared and 
the pattern variables have the corresponding names. But they are binding oc¬ 
currences, not references to the hypotheses. The scope of a rule’s hypotheses 
extends only to its conclusion; each problem and subproblem has its own scope. 

Sheds ]J] are where we develop solutions. The basic editing operation in 
Epigram is to expose the contents of a shed to the elaborator. We can write 
the whole program in one shed, then elaborate it; or we can work a little at a 
time. If we select a shed, Epigram will tell us what’s in scope (here, x, y in Nat), 
and what we’re supposed to be doing with it (here, explaining how to compute 
plus x y in Nat). We may proceed by filling in a right-hand side, explaining 
how to reduce the current problem to zero or more subproblems. 

I suggest that we seek to define plus by structural recursion on x, entering 
the right-hand side <= recx. The l <=’ is pronounced ‘by’: it introduces right-hand 
sides which explain by what means to reduce the problem. Here we get 


plus x y <= 


Plus x y |[] } 


Apparently, nothing has changed. There is no presumption that recursion on 
x will be accompanied immediately (or ever) by case analysis on a;. If you select 
the shed, you’ll see that something has changed—the context of the problem has 
acquired an extra hypothesis, called a memo-structure. A precise explanation 
must wait, but the meaning of the problem is now ‘construct plus x y, given 
x, y and the ability to call to plus on structural subterms of x\ So let us now 
analyse x, proceeding -*= case x. 


plus xy <= rec x I 
plus x y <= case x { 



The two subproblems are precisely those corresponding to the two ways x 
could have been made by constructors of Nat. We can certainly finish the first 



one off, entering =>• y. (The ‘ ’ is ‘return’.) We can make some progress on 

the second by deciding to return the successor of something, => sue 


plus x y <= rec a: \ 


plus x y <= case x { 

plus zero y => y 

plus (sue x) y =$■ sue [||| }} 


Select the remaining shed and you’ll see that we have to fill in an element 
of Nat, given x, y and a subtly different memo-structure. Case analysis has 
instantiated the original argument, so we now have the ‘ability to make recursive 
calls to plus on structural subterms of (sue x)' which amounts to the more 
concrete and more useful ‘ability to make recursive calls to plus on structural 
subterms of x, and on x itself’. Good! We can finish off as follows: 


plus x y <= rec x { 


plus x y <= case x { 
plus zero y => y 

plus (sue x) y => sue (plus x y) }} 


2.1 Who did the Work? 

Two pages to add unary numbers? And that’s a simple example? If it’s that 
much like hard work, do we really want to know? Well, let’s look at how much 
was work and how much was culture shock. We wrote the bits in the boxes: 



We wrote the type signature: we might have done that for virtue’s sake, 
but virtue doesn’t pay the rent. Here, we were repaid—we exchanged the usual 
hand-written left-hand sides for machine-generated patterns resulting from the 
conceptual step (usually present, seldom written) •<= case x. This was only 
possible because the machine already knew the type of x. We also wrote the 
<= rec a:, a real departure from conventional practice, but we got repaid for that 
too—we (humans and machines) know that plus is total. 

Perhaps it’s odd that the program’s text is not entirely the programmer’s 
work. It’s the record of a partnership where we say what the plan is and the 
machine helps us carry it out. Contrast this with the ‘type inference’ model of 
programming, where we write down the details of the execution and the machine 
tries to guess the plan. In its pure form, this necessitates the restriction of plans 
to those which are blatant enough to be guessed. As we move beyond the Hindley- 
Milner system, we find ourselves writing down type information anyway. 









‘Type inference’ thus has two aspects: ‘top-level inference’—inferring type 
schemes, as with Hindley-Milner ‘let’—and ‘program inference given types’— 
inferring details when a scheme is instantiated, as with Hindley-Milner variables. 
Epigram rejects the former, but takes the latter further than ever. As types 
represent a higher-level design statement than programs, we should prefer to 
write types if they make programs cheaper. 

Despite its interactive mode of construction, Epigram is fully compliant with 
the convention that a file of source code, however manufactured, contains all 
that’s required for its recognition as a program. The bare text, without colour 
or other markup, is what gets elaborated. The elaboration process for a large 
code fragment just reconstructs a suitable interactive development offstage, cued 
by the program text—this is how we reload programs. You are free to negotiate 
your own compromise between incremental and batch-mode programming. 

2.2 Where are the Dependent Types? 

The type of plus is unremarkably simple, but if you were watching closely, you’ll 
have noticed that the machine was using dependent types the whole time. Let’s 
take a closer look. Firstly, a thought experiment—define a primitive recursion 
operator for Nat in Haskell as follows: 

primRec{-p:: Nat -> p -> (Nat -> p -> p) -> p 
primRec{-pZero mz ms = mz 

primRecj- p -} (Sue n) mz ms = ms n (primRec{-p -} n mz ms) 

I’ve made primRec’s type parameter explicit in a comment so we can follow 
what happens as we put it to work. How might we write plus? Try applying 
primRec to the first argument, then checking what’s left to do: 

plus :: Nat -> Nat -> Nat 

plus = \ x -> primRecj-Nat -> Nat -} x mz ms where 

mz :: Nat -> Nat — fill this in 

ms :: Nat -> (Nat -> Nat) -> Nat -> Nat — fill this in 

Now we must fill in the methods mz and ms, but do their types show what 
role they play? There are seven occurrences 6 of Nat in their types—which is 
which? Perhaps you can tell, because you understand primRec, but how would 
a machine guess? And if we were defining a more complex function this way, we 
might easily get lost—try defining equality for lists using f oldr. 

However, recall our Natlnd principle with operational behaviour just like 
primRec but a type which makes clear the relationship between the methods 
and the patterns for which they apply. If we’re careful, we can use that extra 
information to light our way. Where primRec takes a constant type parameter, 
Natlnd takes a function P : Nat —► *. If we take P x Nat —► Nat, we 

6 If I had chosen a first-order recursion, there would have been as few as four, but that 
would presume to fix the second argument through the course of the recursion. 



get the primRec situation. How might we use P’s argument to our advantage? 
Internally, Epigram doesn’t build plus : Nat — > Nat — > Nat but rather a proof 

Oplus : \/x, y : Nat => (plus x y : Nat) 

We can interpret (plus x y : Nat) as the property of x and y that ‘plus x y is 
a computable element of Nat’. This type is equipped with a constructor which 
packs up values and a function which runs computations 

_ ? _ n : Nat _ c : (plus x y : Nat) 

return (plus x y) n : (plus x y : Nat) call(plus x y ) c : Nat 

such that 

call(plus x y) (return (plus x y) n) n 
Given Oplus, we may readily extract plus— apply and run! 

plus Xx, y => call(plus x y) (Oplus x y) : Nat — ► Nat — > Nat 
Now, let’s build Oplus as a proof by Natlnd: 

Oplus Natlnd (Aa: =► My: Nat => (plus x y : Nat)) mz ms 
where mz : Vy:Nat=> (pluszeror/: Nat) 

ms : Mx : Nat =>- (My: Nat => (plus x y : Nat)) 

—> My: Nat =>- (plus (sue a;) y : Nat) 

It’s not hard to see how to generate the left-hand sides of the subproblems 
for each case—just read them off from their types! Likewise, it’s not hard to see 
how to translate the right-hand sides we supplied into the proofs—pack them 
up with return( • ■ ■ ) translate recursive calls via call( • • ■ ): 

mz Xy => return (plus zero y) y 

ms Aa; => Xxhyp => Xy => 

return(plus (sue x) y) (sue (call(plus x y) ( xhyp y))) 

Prom this proof, you can read off both the high-level program and the its low-level 
operational behaviour in terms of primitive recursion. And that’s basically how 
Epigram works! Dependent types aren’t just the basis of the Epigram language — 
the system uses them to organise even simply typed programming. 


2.3 What are case and rec ? 

In the plus we actually wrote, we didn’t use induction—we used case x and 
rec x. These separate induction into its aspects of distinguishing constructors 
and of justifying recursive calls. The keywords case and rec cannot stand alone, 
but case e and rece are meaningful whenever e belongs to a datatype—Epigram 
constructs their meaning from the structure of that datatype. 




In our example, x : Nat, and Epigram give 


case x : VP : Nat —> * =>■ 

(P zero) —» (Vad: Nat =>■ P (sue x')) —> P x 

This is an induction principle instantiated at x with its inductive hypotheses 
chopped off: it just says, ‘to do P with x, show how to do P with each of these 
patterns’. The associated computational behaviour puts proof into practice: 

( case zero) P mz ms ~>- mz 
( case (sue x)) P mz ms ^ ms x 

There is nothing special about case a;. When elaborating <= e, it’s the type of 
e which specifies how to split a problem into subproblems. If, as above, we take 

P Aa; Vy : Nat => { plus x y : Nat) 

then the types of mz and ms give us the split we saw when we wrote the program. 
What about rec x? 

rec x : VP : Nat —> * => 

(Va:: Nat =>■ (memo x) P —* P x) —► 

Px 

This says ‘if you want to do P x, show how to do it given access to P for ev¬ 
erything structurally smaller than x\ This ( memo ad is another gadget generated 
by Epigram from the structure of ads type—it uses the power of computation in 
types to capture the notion of ‘structurally smaller’: 

( memo zero) P ^ One 

(memo (sue n)) P (memo n) P A P n 

That is ( memo ad P is the type of a big tuple which memoizes P for everything 
smaller than x. If we analyse x, the memo-structure computes, 7 giving us the 
trivial tuple for the zero case, but for (sue n), we gain access to P n. Let’s watch 
the memo-structure unfolding in the inevitable Fibonacci example. 

fib n <= rec n { 
fib n <= case n { 
fib zero => zero 
fib (sue n) <= case n { 
fib (sue zero) => sue zero 
fib (sue (sue n)) => [] }}} 

Following a suggestion by Thierry Coquand, Eduardo Gimenez shows how to sep¬ 
arate induction into case and rec in [17]. He presents memo-structures inductively, 
to justify the syntactic check employed by Coq’s Fix construct. The computational 
version is mine [23]; its unfolding memo-structures give you a menu of recursive calls. 


— \ fib n : Nat i 




If you select the remaining shed, you will see that the memo structure in the 
context has unfolded (modulo trivial algebra) to: 

(memo n) (Xx =$■ (fib x : Nat)) A (fib n: Nat) A (fib (sue n) : Nat) 

which is just as well, as we want to fill in plus (fib n) (fib (sue n)). 

At this stage, the approach is more important than the details. The point is 
that programming with <= imposes no fixed notion of case analysis or recursion. 
Epigram does not have ‘pattern matching’. Instead, -*= admits whatever notion of 
problem decomposition is specified by the type of the expression (the eliminator) 
which follows it. The value of the eliminator gives the operational semantics to 
the program built from the solutions to the subproblems. 

Of course, Epigram equips every datatype with case and rec . giving us the 
usual notions of constructor case analysis structural recursion. But we are free 
to make our own eliminators, capturing more sophisticated analyses or more 
powerful forms of recursion. By talking about patterns , dependent types give us 
the opportunity to specify and implement new ways of programming. 


2.4 Pause for Thought 

Concretely, we have examined one datatype and two programs. Slightly more 
abstractly, we have seen the general shape of Epigram programs as decision 
trees. Each node has a left-hand side, stating a programming problem p, and 
a right-hand-side stating how to attack it. The leaves of the tree p => t ex¬ 
plain directly what value to return. The internal nodes p <= e use the type of 
the eliminator e as a recipe for reducing the problem statement to subproblem 
statements, and the value of e as a recipe for solving the whole problem, given 
the solutions to the subproblems. Every datatype is equipped with eliminators 
of form case x for constructor case analysis and rec x for structural recursion, 
allowing us to construct obviously total programs in a pattern matching style. 

However, the <= construct is a more general tool than the case construct of 
conventional languages. We answer Wadler’s question of how to combine data 
abstraction with notions of pattern matching [38] by making notions of pattern 
matching first-class values. 

It’s reasonable to ask ‘Can’t I write ordinary programs in an ordinary way? 
Must I build decision trees?’. I’m afraid the answer, for now, is ‘yes’, but it’s 
just a matter of syntactic sugar. We’re used to prioritized lists of patterns with 
a ‘take the first match’ semantics [28]. Lennart Augustsson showed us how to 
compile these into trees of case-on-variables [3]. Programming in Epigram is 
like being Augustsson’s compiler—you choose the tree, and it shows you the 
patterns. The generalization lies in what may sit at the nodes. One could flatten 
those regions of the tree with nonempty •<= case x nodes and use Augustsson’s 
algorithm to recover a decision tree, leaving <= explicit only at ‘peculiar’ nodes. 

Of course, this still leaves us with explicit rec x supporting structural 
recursion. Can we get rid of that? There are various methods of spotting safe 
recursive calls [17]; some even extend to tracking guardedness through mutual 


definitions [1]. We could use these to infer obvious appeals to rec, leaving only 
sophisticated recursions explicit. Again, it’s a question of work. Personally, I 
want to write functions which are seen to be total. 

Some might complain ‘What’s the point of a programming language that isn’t 
Turing complete?’, but I ask in return, ‘Do you demand compulsory ignorance 
of totality?’. Let’s guarantee totality explicitly whenever we can [37]. It’s also 
possible, contrary to popular nonsense, to have dependent types and general 
recursive programs, preserving decidable typechecking: the cheapest way to do 
this is to work under an assumed eliminator with type 

VP :★ =k (P — » P) -* P 

to which only the run time system gives a computational behaviour; a less drastic 
way is to treat general recursion as an impure monadic effect. 

But in any case, you might be surprised how little you need general recursion. 
Dependent types make more programs structurally recursive, because dependent 
types have more structure. Inductive families with inductive indices support 
recursion on the data itself and recursion on the indices. For example, first- 
order unification [36] becomes structurally recursive when you index terms by 
the number of variables over which they are constructed—solving a variable may 
blow up the terms, but it decreases this index [25]. 


2.5 Some Familiar Datatypes 

Just in time for the first set of exercises, let’s declare some standard equipment. 
We shall need Bool, which can be declared like so: 


data Bool : * where true, false : Bool 
The standard Maybe type constructor is also useful: 


( X : * 

‘ l Maybe A : - 


nothing : Maybe A' 


just x : Maybe A 


Note that I didn’t declare A in the rules for nothing and just. The hypotheses 
of a rule scope only over its conclusion, so it’s not coming from the Maybe rule. 
Rather, in each rule Epigram can tell from the way A is used that it must be a 
type, and it silently generalizes the constructors, just the way the Hindley-Milner 
system generalizes definitions. 

It’s the natural deduction notation which triggers this generalization. We 
were able to define Bool without it because there was nothing to generalize. 
Without the rule to ‘catch’ the A, plain 

nothing : Maybe A 


wouldn’t exactly be an error. The out-of-scope A is waiting to be explained by 
some prior definition: the nothing constructor would then be specific to that A. 







Rule-induced generalization is also happening here, for polymorphic lists: 


^ ( l-isfx*« ) ( nil : Ust jc ) • ( “confxxT Li?/ ) 

We also need the binary trees with TV-labelled nodes and i-labelled leaves. 


( N,L : 


— Tree TV T : 


where 


l : L \ 

leaf l : Tree N L J 


( n : TV ; s,t : Tree TV L \ 
^ node n s t : Tree TV L J 


2.6 Exercises: Structural Merge-Sort 

To get used to the system, and to programming with structural recursion, try 
these exercises, which only involve the simple types above 

Exercise 1 (le) Define the ‘less-or-equal’ test: 

let ( /.y : NfO 
— 11 ex y : Bool I 

Does it matter which argument you do rec on? 

Exercise 2 (cond) Define the conditional expression: 

, . / b : Bool ; then, else : T \ 

— y cond b then else : T J 

Exercise 3 (merge) Use the above to define the function which merges two 
lists, presumed already sorted into increasing order, into one sorted list contain¬ 
ing the elements from both. 

xs, ys : List Nat 
merge xs ys : List Nat 

Is this function structurally recursive on just one of its arguments ? Nested rec s 
combine lexicographically. 

Exercise 4 (flatten) Use merge to implement a function flatten ing a tree 
which may have numbers at the leaves, to produce a sorted list of those numbers. 
Ignore the node labels. 

, ft: Tree TV (Maybe Nat) \ 

— I flatten t : List Nat J 

We can have a structurally recursive O(nlogn) sorting algorithm if we can 
share out the elements of a list into a balanced tree, then flatten it. 













Exercise 5 (insert) Implement the insertion of a number into a tree: 

, , ( n : Nat; t : Tree Bool (Maybe Nat) \ 

— I insert n t : Tree Bool (Maybe Nat) J 

Maintain this balancing invariant throughout: in (nodetrues t), s and t contain 
equally many numbers, whilst in (node false s t), s contains exactly one more 
number than t. 

Exercise 6 (share, sort) Implement 


ns : List Nat _ 

: Tree Bool (Maybe Nat) 


— ^ sort ns : List Nat ) 
i that sort sorts its input in O(nlogn) time. 


3 Vectors and Finite Sets 

Moving on to dependent data structures n 
data ( 71 where 


Vec n X : 


r , let’s take a closer look at Vec: 


vnil : Vec zero X I 


I x : X ■, xs : MecnX 

l vcons x xs : Vec (sue n) X 


The generalization mechanism ensures that all the previously undeclared 
variables arising inside each deduction rule are silently quantified in the resulting 
type, with the implicit V_ quantifier. Written out in full, we have declared 


data Vec : Nat - 
where vnil : V_X 
vcons : V.X : i 


=*> Vec zero X 
=^V_n: Nat =>X - 


Vec nl -> Vec (sue n) X 


On usage, Epigram tries to infer arguments for expressions with implicitly 
quantified types, just the way the Hindley-Milner system specializes polymor¬ 
phic things—by solving the equational constraints which arise in typechecking. 
However, Epigram needs and supports a ‘manual override’: the postfix _ operator 
inhibits inference and makes an implicit function explicit, so 

vniL : VX :★ =>Vec zero X 
vniLNat : Vec zero Nat 

To save space, I often write overridden arguments as subscripts—eg., vnil Nat . 








Given this definition, let’s start to write some simple programs: 


let 


ys : Vec (sue m ) Y 
vhead ys : Y 


; vhead ys J<= case ys|| 


What happens when we elaborate? Well, consider which constructors can pos¬ 
sibly have made ys. Certainly not vnil, unless zero = sue n. We just get a vcons 
case—the one case we want, for ‘head’ and ‘tail’: 



vhead ys <= case ys { 
vhead (vcons y ys) => y } 



In the latter, not only do we get that it’s vcons as opposed to vnil: it’s the 
particular vcons which extends vectors of the length we need. What’s going on? 
Much as Thierry Coquand proposed in [13], Epigram is unifying the scrutinee 
of the case with the possible constructor patterns, in both term and type: 


ys : Vec (sue m) Y 

unifier 

vnilx : Vec zero X 

impossible 

vconsxn x xs' : Vec (sue n) X 

X = Y,n = m,xs = vconsy m x xs' 


Only the vcons case survives—Epigram then tries to choose names for the pat¬ 
tern variables which maintain a ‘family resemblance’ to the scrutinee, hence the 
(vcons y ys) in the patterns. 

This unification doesn’t just rule cases in or out: it can also feed information 
to type-level computations. Here’s how to append vectors: 



vappend m xs ys <= vec xs { 
vappend m xs ys <= case xs { 
vappend zer0 vnil ys =>■ ys 

vappend( suc TO ) (vcons x xs) ys => vcons x (vappend m xs ys) }} 

I’ve overridden the length arguments just to show what’s happening—you 
can leave them implicit if you like. The point is that by looking at the first 
vector, we learn about its length. This lets plus compute exactly as we need 
for ys : Vec (plus zero n) X in the vnil case. For vcons, the return type is 
Vec (plus (sue m) n) X Vec (sue (plus rn n)) X . which is what we supply. 








3.1 Finite Sets 


Let’s examine the consequences of dependent case analysis for a different family: 

— ( Fin n^ 3 *) (fz : Fin (sue n)) ; (fs i : Fin (sue n)) 

What happens when we elaborate this? 

let | » : fin zero ] ; magic i J<= case i ] 

— I magic i : X ] ’ ° ■ ■ 

You’ve probably guessed, but let’s just check: 


i : Fin zero 

unifier 

fz n : Fin (sue n) 

impossible 

fs„ j : Fin (sue n) 

impossible 


So the finished product is just magic i <= case i 

The idea is that Fin n is an enumeration type containing n values. Let’s 
tabulate the first few members of the family, just to see what’s going on. (I’ll 
show the implicit arguments as subscripts, but write in decimal to save space.) 


Fin 0 

Fin 1 

Fin 2 

Fin 3 

Fin 4 



fzo 

fzi 

fsi fz 0 

fz 2 

fs 2 fzi 

fs 2 (fsi fzo) 

fz 3 

fs 3 fz 2 

fs 3 (fs 2 fzi) 

fs 3 (fs 2 (fsi fzo)) 



Fin zero is empty, and each Fin (sue n) is made by embedding the n ‘old’ 
elements of Fin n, using fs n , and adding a ‘new’ element fz n . Fin n provides a 
representation of numbers bounded by n, which can be used as ‘array subscripts’: 


— I vproj xs i : X 


vproj xs i <= rec xs { 
vproj xs i <= case xs { 
vproj vnil i <= case i 
vproj (vcons x xs) i <= case i { 
vproj (vcons x xs) fz=>x 
vproj (vcons x xs) (fs i) 

=> vproj xs i }}} 


We need not fear projection from vnil, for we can dismiss i : Fin zero, as a 
harmless fiction. Of course, we could have analysed the arguments the other way 

















around: 


vproj xs i <= rec xs { 
vproj xs i <= case i { 
vproj xs fz 4= case xs { 
vproj (vcons x xs) fz => x } 
vproj xs (fs i) <= case xs { 
vproj (vcons x xs) (fs i) => vproj xs i }}} 


Here, inspecting i forces n to be non-zero in each case, so xs can only be a vcons. 
The same result is achieved either way, but in both definitions, we rely on the 
impact the first case analysis has on the possibilities for the second. It may seem 
a tautology that dependent case analyses are not independent, but its impact is 
profound. We should certainly ask whether the traditional case expression, only 
expressing the patterns of its scrutinee, is as appropriate as it was in the past. 


3.2 Refining Programming Problems 

Our unification tables give some intuition to what is happening with case anal¬ 
ysis. In Thierry Coquand’s presentation of dependent pattern matching [13], 
constructor case analysis is hard-wired and unification is built into the typing 
rules. In Epigram, we have the more generic notion of refining a programming 
problem by an eliminator, <= e. If we take a closer look at the elaboration of this 
construct, we’ll see how unification arises and is handled inside the type theory. 
I’ll maintain both the general case and the vtail example side by side. 

As we saw with plus, when we say 8 



Epigram initiates the development of a proof 

Of : VT=^ (fT : R) I 0 vtail : Vm:Nat; Y ys : Vec (sue m) Y 


=>• ( vtail m y ys : Vec m Y ) 


The general form of a subproblem in this development is 

Ofsub : VA =>■ (f p : T) I Ovtail : Vm:Nat; Y ys : Vec (sue m) Y 
| => (vtail m y ys : Vec m Y) 

where p are patterns —expressions over the variables in A. In the example, I’ve 
chosen the initial patterns given by vtails formal parameters. Note that patterns 


I write Greek capitals for sequences of variables with type assignments in binders 
and also for their unannotated counterparts as argument sequences. 




in Epigram are not a special subclass of expression. Now let’s proceed 


f P 


e 


vtail ys <= case ys 


e : V P: V(9 =>* 

rri! : VA\ =>P s± 

m n :VA n ^Ps n 
=> Pt 


P: yn\X\xs: Vec n X =$■* 
mj : V_X :* => P zero X vnil 
ru 2 : V_X _n: Nat 

x:X ■ xs:VecnX 
=> P (sue n) X (vcons x a 
► P (sue m) Y ys 


We call P the motive —it says what we gain from the elimination. In particular, 
we’ll have a proof of P for the t. The m, are the methods by which the motive 
is to be achieved for each s*j. James McKinna taught me to choose this motive: 


VA =► e=t -» 

(fp:T) 


An; X; zs =► 

Vm:Nat; F ys : Vec (sue m) F 
=► n=(suc m) -v X=F ^ xs= 2 /s 
( vtail m y ys : Vec m F ) 


This is just Henry Ford’s old joke. Our motive is to produce a proof of 
'iA =>- (f p : T), for ‘any O we like as long as it’s t ’—the t are the only G we 
keep in stock. For our example, that means ‘any vector you like as long as it’s 
nonempty and its elements are from F’. This = is heterogeneous equality, 9 
which allows any elements of arbitrary types to be proclaimed equal. Its one 
constructor, ref I, says that a thing is equal to itself. 


s : S ; t, : T 
s=t : * 


ref I : t=t 


Above, the types of xs and ys are different, but they will unify if we can solve 
the prior equations. Hypothetical equations don’t change the internal rules by 
which the typechecker compares types—this is lucky, as hypotheses can lie. 

If we can construct the methods, mi, then we’re done: 


Ofsub A A => e P mi .. . m n 

A refl ... refl 

: VA=^ (f p: T) 


Ovtail Am; F; ys l ease ys) P mi m 2 
mYys refl refl refl 
: Vm:Nat; F:*; ys : Vec (sue m) F 
=> ( vtail m y ys : Vec m Y ) 


But what are the methods? We must find, for each i 
mi : VAp, A => Si=t —» (f p : T) 


also known as ‘John Major’ equality [23] 










In our example, we need 


mi : V-X; _m; _F; ys : Vec (sue m) Y =$■ 

zero=(suc m) — ► X=Y —» vnil=ys —* 

( vtail m y ys ■ Vec m Y ) 

m 2 : V_X; _n; x\ xs : Vec n X- _m;_F; xs : Vec (sue m) Y =>• 

(sue n)=(suc m) —► X=F —s- (vcons x xs)=ys —► 

{ vtail m y ys : Vec m F ) 

Look at the equations! They express exactly the unification problems for case 
analysis which we tabulated informally. Now to solve them: the rules of first-order 
unification for data constructors—see figure 1—are derivable in UTT. Each rule 


deletion 

P 


x=x-^P 

conflict 

chalk s=cheese t — > P 

injectivity 

(g=t -> P) - 


chalk s=chalk £ —► P 

substitution 

Pt -> x,t : T-,x <£ FV(t) 


x=t -t Pi 

cycle 

x=t —► P x constructor-guarded in t 


Fig. 1. derivable unification rule schemes 


(read backwards) simplifies a problem with an equational hypothesis. We apply 
these simplifications to the method types. The conflict and cycle rules dispose 
of ‘impossible case’ subproblems. Meanwhile, the substitution rule instantiates 
pattern variables. In general, the equations Si=t will be reduced as far as possible 
by first-order unification, and either the subproblem will be dismissed, or it will 
yield some substitution, instantiating the patterns p. 

In our example, the vnil case goes by conflict, and the vcons case becomes: 

V_ Y ; _ro; x : Y;xs: Vec Y m => ( vtail y m (vcons x xs) : Vec Y m ) 

After ‘cosmetic renaming’ gives x and xs names more like the original ys, we get 

vtail (vcons y ys) j|] 

To summarize, elaboration of <= e proceeds as follows: 

(1) choose a motive with equational constraints; 

(2) simplify the constraints in the methods by first-order unification; 

(3) leave the residual methods as the subproblems to be solved by subprograms. 



In the presence of defined functions and higher types, unification problems 
won’t always be susceptible to first-order unification, but Epigram will make 
what progress it can and leave the remaining equations unsolved in the hypothe¬ 
ses of subproblems—later analyses may reduce them to a soluble form. Moreover, 
there is no reason in principle why we should not consider a constraint-solving 
procedure which can be customized by user-supplied rules. 

3.3 Reflection on Inspection 

We’re not used to thinking about what functions really tell us, because simple 
types don’t say much about values, statically. For example, we could write 



nonzero n <= case n { 
nonzero zero =>■ false 
nonzero (sue n) => true } 


but suppose we have xs : Vec n X —what do we learn by testing nonzero n? 
All we get is a Bool, with no direct implications for our understanding of n or 
xs. We are in no better position to apply vtail to xs after inspecting this Bool 
than before. Instead, if we do case analysis on n, we learn what n is statically 
as well as dynamically, and in the sue case we can apply vtail to xs. 

Of course, we could think of writing a preVtail function which operates on 
any vector but requires a precondition, like 



I’m not quite sure what to write as the length of the returned vector, so I’ve left 
a shed: perhaps it needs some kind of predecessor function with a precondition. 
If we have ys : Vec (sue m ) Y . then preVtail ys refl will be well typed. We could 
even use this function with a more informative conditional expression: 

condlnfo : VP:*; 6:Bool=^ (&=true — > P) — > (6=false — > P) — > P 

However, this way of working is clearly troublesome. 

Moreover, given a nonempty vector xs , there is more than just a stylistic 
difference between decomposing it with vhead and vtail and decomposing it 
with l ease xs )— the destructor functions give us an element and a shorter vec¬ 
tor; the case analysis tells us that xs is the vcons of them, and if any types 
depend on xs, that might just be important. Again, we can construct a proof of 
a;.s=vcons (vhead xs) (vtail xs), but this is much harder to work with. 

In the main, selectors-and-destructors are poor tools for working with data 
on which types depend. We really need forms of inspection which yield static 
information. This is a new issue, so there’s no good reason to believe that the 
old design choices remain appropriate. We need to think carefully about how to 
reflect data’s new role as evidence. 




3.4 Vectorized Applicative Programming 


Now that we’ve seen how dependent case analysis is elaborated, let’s do some 
more work with it. The next example shows a key difference between Epigram’s 
implicit syntax and parametric polymorphism. The operation 



makes a vector of copies of its argument. For any given usage of vec, the intended 
type determined the length, but how are we to define vec? We shall need to work 
by recursion on the intended length, hence we shall need to make this explicit 
at definition time. The following declaration achieves this: 



vec zer0 x => vnil 

vec( sucr j) x =>• vcons a; (vec n x) }} 


Note that in vec’s type signature, I explicitly declare n first, thus making it the 
first implicit argument: otherwise, X might happen to come first. By the way, 
we don’t have to override the argument in the recursive call vec,„ x — it’s got 
to be a Vec n X —but it would perhaps be a little disconcerting to omit the n, 
especially as it’s the key to vec’s structural recursion. 

The following operation—vectorized application—turns out to be quite handy. 



va fs ss <= reefs { 
va fs ss <= case fs { 
vavnilss <= case ss { 
va vnil vnil => vnil } 
va (vcons / fs) ss <= case ss { 
va (vcons f fs) (vcons s ss) => vcons (/ s) (va fs ss) }}} 


As it happens, the combination of vec and va equip us with ‘vectorized ap¬ 
plicative programming’, with vec embedding the constants, and va providing 
application. Transposition is my favourite example of this: 



transpose xij <= rec xij { 
transpose xij <= case xij { 

transpose vnil => vec vnil 

transpose (vcons xj xij) => va (va (vec vcons) xj) (transpose xij) }} 






3.5 Exercises: Matrix Manipulation 

Exercise 7 (vmap, vZipWith) Show how vec and va can be used to generate 
the vector analogues of Haskell’s map, zipWith, and the rest of the family. (A 
glance at [16] may help.) 

Exercise 8 (vdot) Implement vdot , the scalar product of two vectors of Nats. 
Now, how about matrices? Recall the vector-of-columns representation: 

let ^ Matrix rows ‘cofe^ Matrix rows cols => Vec cols (Vec rows Nat) 

Exercise 9 (zero, identity) How would you compute the zero matrix of a 
given size? Also implement a function to compute any identity matrix. 

Exercise 10 (matrix by vector) Implement matrix-times-vector multiplica¬ 
tion. (ie, interpret a Matrix mn as a linear map Vec n Nat — > Vec m Nat.,) 

Exercise 11 (matrix by matrix) Implement matrix-times-matrix multiplica¬ 
tion. (ie, implement composition of linear maps.) 

Exercise 12 (monad) (Mainly for Haskellers.) It turns out that for each n, 
Vec n is a monad, with vec playing the part of return. What should the corre¬ 
sponding notion of join do? What plays the part of ap? 


3.6 Exercises: Finite Sets 


Exercise 13 (fmax, fweak) Implement frnax (each nonempty set’s maximum 
value) and fweak (the function preserving fz and fs, incrementing the index). 


Fin (sue n) J ~ i fweak i : Fin (sue n) 


You should find that fmax and fweak partition the finite sets, just as fz and fs 
do. Imagine how we might pretend they’re an alternative set of constructors... 


Exercise 14 (vtab) Implement -v tab, the inverse o/vproj, tabulating a func¬ 
tion over finite sets as a vector. 


let 


(n: Nat; f : Fin n -> x\ 
1 vtab n / : Vec n X ) 


Note that vtab and vproj offer alternative definitions of matrix operations. 


Exercise 15 (OPF, opf) Devise an inductive family, OPF m n which gives a 
unique first-order representation of exactly the order-preserving functions in 
Fin m —* Fin n. Give your family a semantics by implementing 


let 


/ : OPF m n ; i : Fin 

opf f i : Fin n 







Exercise 16 (iOPF, cOPF) Implement identity and composition: 


— I iOPF„ : OPFrc 


/ OPF n 


g OPF l r, 


cOPF f g : OPF / n 


Which laws should relate iOPF, cOPF and opf? 


4 Representing Syntax 

The Fin family can represent de Bruijn indices in nameless expressions [14], As 
Frangoise Bellegarde and James Hook observed in [6], and Richard Bird and 
Ross Paterson were able to implement in [9], you can do this in Haskell, up to a 
point—here are the A-terms with free variables given by v: 
data Term v = Var v 

I App (Term v) (Term v) 

I Lda (Term (Maybe v)) 

Under a Lda, we use (Maybe v) as the variable set for the body, with Nothing 
being the new free variable and Just embedding the old free variables. Renaming 
is just fmap, and substitution is just the monadic ‘bind’ operator »=. 

However, Term is a bit too polymorphic. We can’t see the finiteness of the 
variable context over which a term is constructed. In Epigram, we can take the 
number of free variables to be a number n. and choose variables from Fin n. 


data 


( n : Nat N 
l Tm n : * i 


/, s : Tm n 

app / s : Tm n 


t : Tm (sue n) 
Ida t : Tm n 


The n in Term n indicates the number of variables available for term formation: 
we can explain how to A-lift a term, by abstracting over all the available variables: 


— I ldaLift ra t : Tm zero ) 


ldaLift r , t 
ldaLift n 
ldaLift z 
ldaLift( suc „) t 


- case n { 


• ldaLift n (Ida t) }} 


Not so long ago, we were quite excited about the power of non-uniform 
datatypes to capture useful structural invariants. Scoped de Bruijn terms gave a 
good example, but most of the others proved more awkward even than the ‘fake’ 
dependent types you can cook up using type classes [24]. 

Real dependent types achieve more with less fuss. This is mainly due to the 
flexibility of inductive families. For example, if you wanted to add ‘weakening’ to 
delay explicitly the shifting of a term as you push it under a binder—in Epigram, 
but not Haskell or Cayenne, you could add the constructor 

t : Tm n 

weak t : Tm (sue n) 










4.1 Exercises: Renaming and Substitution 


If Fin m is a variable set, then some p : Fin m —> Fin n is a renaming. If we want 
to apply a renaming to a term, we need to be able to push it under a Ida. Hence 
we need to weaken the renaming, mapping the new source variable to the new 
target variable, and renaming as before on the old variables. 10 


let 


p : Fin n 


+ Fin n 


: Fin (sue n 


wren pi : Fin (sue n) 


wren pi <= case i { 
wrenpfz => fz 
wren p (fs i) => fs (p i) } 


You get to finish the development. 

Exercise 17 (ren) Use wren to help you implement the renaming traversal 


iet ( P ■ Finm->Finn; t : Tm m \ 

— I ren p t : Tm n J 

Now repeat the pattern for substitutions—functions from variables to terms. 

Exercise 18 (wsub, sub) Develop weakening for substitutions, then use it to 
go under Ida in the traversal: 


: Fin m — > Tm n ; i : Fin (sue m) 
wsub a i : Tm (sue n) 


-> Tm n ; t : Tm n 


Exercise 19 (For the brave.) Refactor this development, abstracting the weakening- 
then-traversal pattern. If you need a hint, see chapter 7 of [23]. 


4.2 Stop the World I Want to Get Off! (a first try at typed syntax) 

We’ve seen untyped A-calculus: let’s look at how to enforce stronger invariants, by 
representing a typed A-calculus. Recall the rules of the simply typed A-calculus: 

_ rimo±jt€r rjmesrpr rhe<r 

r-,x£a-,r' hie? r\- Xxea.teaDr rh/ser 

Well-typed terms are defined with respect to a context and a type. Let’s just 
turn the rules into data! I add a base type, to make things more concrete. 



10 Categorists! Note wren makes sue a functor in the category of Fin-functions. What 
other structure can you sniff out here? 













We could use Vec for contexts, but I prefer contexts which grow on the right. 

data ( c rl V I where (--- cr , - | 

- ^ SCtxt n : kj - l empty : SCtxtzero ] 

( r : SCtxt n ■ a : SType 

1 bind P a : SCtxt (sue n) 

Now, assuming we have a projection function sproj, defined in terms of SCtxt 
and Fin the way we defined vproj, we can just turn the inference rules of the 
typing relation into constructors: 


data 

where 


( r : SCtxt n ; r : SType \ 

^ STm r t : -k ) 

f _ i : Fin n _\ ( t : STm (bind P a) r \ 

l svar z : STm P (sproj P i) J ’ l slda f : STm P (sFun a r) J 

I f : STm r (sFun a t) ; s : STm r a \ 

l sapp/ s : STm Ft J 


This is a precise definition of the simply-typed A-terms. But is it any good? Well, 
just try writing programs with it. 

How would you implement renaming ? As before, we could represent a re¬ 
naming as a function p : Fin m — > Fin n. Can we rename a term in STm fr to 
get a STm A r, where F : SCtxt rri and A : SCtxt n? Here comes the crunch: 

■ • • ren n r A P (svar i) => jsvar ( p i ) 

The problem is that svar i : STm F (sproj F i), so we want a STm A (sproj F 1) 
on the right, but we’ve got a STm A (sproj A (p i )). We need to know that p is 
type-preserving! Our choice of variable representation prevents us from building 
this into the type of p. We are forced to state an extra condition: 


Vz : Fin m => sproj P z=sproj A ( p i) 

We’ll need to repair our program by rewriting with this proof. 11 But it’s worse 
than that! When we move under a slda, we’ll lift the renaming, so we’ll need a 
different property: 

¥*': Fin (sue m ) => sproj (bind P a) z'=sproj (bind A a) (lift p i') 


This follows from the previous property, but it takes a little effort. My program 
has just filled up with ghastly theorem-proving. Don’t dependent types make life 
a nightmare? Stop the world I want to get off! 

If you’re not afraid of hard work, you can carry on and make this program 
work. I think discretion is the better part of valour—let’s solve the problem in¬ 
stead. We’re working with typed terms but untyped variables, and our function 
which gives types to variables does not connect the variable clearly to the con¬ 
text. For all we know, sproj always returns sNat! No wonder we need ‘logical 
superstructure’ to recover the information we’ve thrown away. 

11 I shan’t show how to do this, as we shall shortly avoid the problem. 












4.3 Dependent Types to the Rescue 


Instead of using a program to assign types to variables and then reasoning about 
it, let’s just have typed variables, as Thorsten Altenkirch and Bernhard Reus [2]. 


data 

where 


( P : SCtxt n ; 


: SType \ 


SVarT 
vz : SVar (bind P a) a 


i : SVarT r 

: SVar (bind P a) t 


This family strongly resembles Fin. Its constructors target only nonempty con¬ 
texts; it has one constructor which references the ‘newest’ variable; the other 
constructor embeds the ‘older’ variables. You may also recognize this family as 
an inductive definition of context membership. Being a variable means being a 
member of the context. Fin just gives a data representation for variables without 
their meaning. Now we can replace our awkward svar with 


( i : SVar fr \ 
V svar i : STm fr I 


A renaming from T to A becomes an element of 


Vr : SType => SVar P r — > SVar A r 


Bad design makes for hard work, whether you’re making can-openers, doing 
mathematics or writing programs. It’s often tempting to imagine that once we’ve 
made our representation of data tight enough to rule out meaningless values, our 
job is done and things should just work out. This experience teaches us that more 
is required—we should use types to give meaningful values their meaning. Fin 
contains the right data, but SVar actually explains it. 

Exercise 20 Construct simultaneous renaming and simultaneous substitution 
for this revised definition o/STm. Just lift the pattern from the untyped version! 


4.4 Is Looking Seeing? 

It’s one thing to define data structures which enforce invariants and to write 
programs which respect invariants, but how can we establish invariants? 

We’ve seen how to use a finite set to index a vector, enforcing the appropriate 
bounds, but what if we only have a number , sent to us from the outside world? 
We’ve seen how to write down the STms, but what if we’ve read in a program 
from a file? How do we compute its type-safe representation if it has one? 

If we want to index a Vec nlbym : Nat, it’s no good testing the Boolean 
m < n. The value true or false won’t explain whether m can be represented by 
some i : Fin n. If we have a / : STm P (sFun a r) and some a : STm P a , we could 
check Boolean equality o == a, but true doesn’t make a into a, so we can’t 
construct sapp f a. 






Similar issues show up in the ‘Scrap Your Boilerplate’ library of dynamically 
typed traversal operators by Ralf Lammel and Simon Peyton Jones [18]. The 
whole thing rests on a ‘type safe cast’ operator, comparing types at run time: 

cast :: (Typeable a, Typeable b) => a -> Maybe b 
cast x = r 


where 

r = if typeOf x == typeOf (get r) 
then Just (unsafeCoerce x) 
else Nothing 

get :: Maybe a -> a 
get x = undefined 


This program does not, of itself, make sense. The best we can say is that 
we can make sense of it, provided typeOf has been correctly implemented. The 
machine looks at the types but does not see when they are the same, hence 
the unsaf eCoerce. The significance of the test is obscure, so blind obedience is 
necessary. Of course, I trust them, but I think they could aspire for better. 

The trouble is that representing the result of a computation is not enough: 
you need to know the meaning of the computation if you want to justify its 
consequences. A Boolean is a bit uninformative. To see when we look, we need 
a new way of looking. Take the vector indexing example. We can explain which 
number is represented by a given i : Fin n by forgetting its bound: 



fFinfz zero 

fFin (fs i) => sue (fFin i) }} 


Now, for a given n and m, m is either 

— (fFin i ) for some i : Fin n, or 

— (plus n m') for some m' : Nat 

Our types can talk about values—we can say that! 


checkBound n m : VP : Nat — > Nat — > -k => 


(Vn: Nat; i : Fin n =>■ P n (fFin *)) — > 
(Vn, m' : Nat => P n (plus n m ')) —► 


Pnm 


That’s to say: ‘whatever P you want to do with n and m, it’s enough to 
explain P for n and (fFin i ) and also for n and (plus n m')' . Or ‘you can match 
n, m against the patterns , n, (fFin i) and n, (plus n m')\ I designed the above 
type to look like a case principle, so that I can program with it. Note that I don’t 
just get an element either of (Fin i) or of Nat from an anonymous informant; it 



really is my very own n and nn which get analysed—the type says so! If I have 
checkBound, then I can check m like this: 


xs : Vec n X ; m : Nat 


— I mayProj ra xs m : Maybe X 


may Pro j n xs m <= checkBound n rn { 
mayProj„ xs (fFin i) =>- just (vproj xs i) 
mayProj„ xs (plus n m') =>• nothing } 


In one case, we get a bounded i, so we can apply bounds-safe projection. 
In the other, we clearly fail. Moreover, if the return type were to depend on 
m, that’s fine: not only do we see what m must be, Epigram sees it too! But 
checkBound has quite a complicated higher-order type. Do I really expect you 
to dump good old m < n for some bizarre functional? Of course I don’t: I’ll now 
explain the straightforward first-order way to construct checkBound. 

4.5 A Funny Way of Seeing Things 

Constructor case analysis is the normal way of seeing things. Suppose I have 
a funny way of seeing things. We know that •<= doesn’t care—a ‘way of seeing 
things’ is expressed by a type and interpreted as a way of decomposing a pro¬ 
gramming problem into zero or more subproblems. But how do I establish that 
my funny way of seeing at things makes sense? 

Given n, m : Nat, we want to see rn as either (fFin i) for some i : Fin n, or 
else some (plus n rn'). We can write a predicate which characterizes the n and 
m for which this is possible—it’s possible for the very patterns we want. 12 



A value be : BoundCheck n m tells us something about n and rn, and it’s just 
n and m that we care about here — be is just a means to this end. The eliminator 
( case be) expects a motive abstracting over n, m and be, allowing us to inspect 
be also. If we restrict the motive to see only n and m, we get 


XP : Nat —► Nat — > * => (case be) (A n'\ m'\ be' =>P n'm ! j 
: VP : Nat —» Nat —> * => 

(Vra: Nat; i : Fin n =$■ P n (fFin *)) —» 

(Vn, m' : Nat => P n (plus n m')) —> 

Pnm 


I forgot that I’m programming-, of course, I mean ‘datatype family’. 







and that’s exactly the type of checkBound nm . This construction on a predicate 
is sufficiently useful that Epigram gives it a special name, ( View be). That’s to 
say, the machine-generated eliminator which just looks at BoundCheck’s indices 
in terms of its constructors. Logically, view gives a datatype family its relation 
induction principle. But to use this ‘view’, we need be : BoundCheck n m. That 
is, we must show that every n and m are checkable in this way: 

— (boundCheck n m : BoundCheck nm 
boundCheck n m <= rec n { 
boundCheck n m <= case n { 
boundCheck zero m => outOfBound m 
boundCheck (sue n) m <= case m { 
boundCheck (sue n) zero =*> inBoundfz 
boundCheck (sue n) (sue m) view (boundCheck nm) { 
boundCheck (sue n) (sue (fFin *)) =>■ inBound (fs i) 
boundCheck (sue n) (sue (plus n m')) => outOfBound m' }}}} 

There’s no trouble using the view we’re trying to establish: the recursive call 
is structural, but used in an eliminator rather than a return value. This function 
works much the way subtraction works. The only difference is that it has a type 
which establishes a connection between the output to the function and its inputs, 
shown directly in the patterns! We may now take 

checkBound n m ^ view (boundCheck n m) 


4.6 Patterns Forget; Matching Is Remembering 

What has ‘pattern matching’ become? In general, a pattern is a forgetful op¬ 
eration. Constructors like zero and sue forget themselves —you can’t tell from 
the type Nat, which constructor you’ve got. Case analysis remembers what con¬ 
structors forget. And so it is with our funny patterns: the fFin function forgets 
bounded whilst (plus n m') forgets by how much its output exceeds n. Our view 
remembers what these patterns forget. 

The difference between Epigram views and Phil Wadler’s views [38] is that 
Epigram views cannot lie. Epigram views talk directly about the values being 
inspected in terms of the forgetful operations which generate them. Wadler’s 
views ascribe that informative significance to an independent value, whether or 
not it’s justified. We shouldn’t criticize Wadler for this—dependent types can 
see where simple types can only look. Of course, to work with dependent types, 
we need to be able to see. If we want to generate values in types which enforce 
strong invariants, we need to see that those invariants hold. 


Exercise 21 Show that fmax and fweak cover Fin by constructing a view. 



5 Well Typed Programs which Don’t Go Wrong 


Let’s have a larger example of derivable pattern matching—building simply- 
typed terms in the STm family by typechecking ‘raw’ untyped terms from 

** (idsb^) 

where ( 1 n " ) 

- y rvar i : RTm n J 

a : SType ; b : _ 

rlda u b : RTm n 


. ( f,s : RTm n \ 
’ l rapp f s : RTm n J 

RTm (sue n) \ 


Typechecking is a form of looking. It relies on two auxiliary forms of looking— 
looking up a variable in the context, and checking that two types are the same. 
Our svar constructor takes context-references expressed in terms of SVar, and 
our sapp constructor really needs the domain of the function to be the same as 
the type of the argument, so just looking is not enough. Let’s see. 

An SVar is a context-reference; a Fin is merely a context-pointer. We can 
clearly turn a reference into a pointer by forgetting what’s referred to: 


let 


; f V t i <= rec i { 
fV r * <= case i { 

fV r vz => fz 

fV T (vs i) =► fc (fV T i) }} 


Why is t an explicit argument? Well, the point of writing this forgetful map 
is to define a notion of pattern for finite sets which characterizes projection. We 
need to see the information which the pattern throws away. Let’s establish the 
view—it’s just a more informative vproj, telling us not only the projected thing, 
but that it is indeed the projection we wanted. 


i : SVarTr 

found r * : Findr(fVrt) 


(find r i : FindTi) 
find r i <= rec F { 
find r i <= case i { 
find r fz <*= case r { 
find (bind T a) fz => found ervz} 
find r (fs i) ■$= case r { 
find (bind F a) (fs i) <= view (find fi) { 
find (bind r a) (fs (fV r «)) => found r (vs i) }}}} 










5.1 Term and Terror 


We can follow the same recipe for typechecking as we did for context lookup. 
Help me fill in the details: 

Exercise 22 (fTm) Implement the forgetful map: 

, , ( r SCtxt n ; t : STm T t\ 


— ^ fTm t t : RTm n J 

But not every raw term is the forgetful image of a well typed term. We’ll need 


^ ( fErrorfW ) 


let 


( r : SCtxt n ; e : TError 

y fTError e : RTm n ) 


Exercise 24 (TError, fTError) Fill out the definition of TError and implement 
fTError. (This will be easy, once you’ve done the missing exercise. The TError, s 
will jump out as we write the typecheckei—they pack up the failure cases.) 


Let’s start on the typechecking view. First, the checkability relation: 


data 


where 


( r : SCtxt n:r : RTm n \ 
V Check Hr : * J 


( t : STm r t \ . 

( e : TError T ^ 

1 good t : Check T (fTm r t) J ’ 

l bad e : Check T (fTError e) J 


Next, let’s start on the proof of checkability—sorry, the typechecker: 

— (check Hr : Check Fr) 
check r r <= rec r { 
check r r <= case r { 
check r (rvar i) <= view (find T i) { 
check T (rvar (fV r i )) =>■ good (svar i) } 
check r (rapp / s) <= view (check T /) { 
check r (rapp (fTm cj)f) s) <= case <t> I 
check r (rapp (fTm sNat/) s) => bad [] 
check T (rapp (fTm (sFun cr r) /) s) <= view (check F s) { 
check T (rapp (fTm (sFun cr r) /) (fTm a s)) J'J j 
check T (rapp (fTm (sFun a r) /) (fTError e)) => bad [] }} 
check T (rapp (fTError e) s) =» bad [] } 
check T (rlda a t) <= view (check (bind T a) t) { 
check T (rlda a (fTm r t )) => good (slda t) 
check r (rlda a (fTError e)) => bad [] }}} 









The story so far: we used find to check variables; we used check recursively 
to check the body of an rlda and packed up the successful outcome. Note that 
we don’t need to write the types of the good terms—they’re implicit in STm. 

We also got some way with application: checking the function; checking that 
the function inhabits a function space; checking the argument. The only trouble 
is that our function expects a a and we’ve got an a. We need to see if they’re 
the same: that’s the missing exercise. 

Exercise 23 Develop an equality view for SType: 



— ^compare or : Compare o r : 

You’ll need to define a representation o/STypes which differ from a given o and 
a forgetful map fDiff which forgets this difference. 

How to go about it? Wait and see. Let’s go back to application... 

check r (rapp (fTm (sFun o t) f) (fTm a s)) <= view (compare o a) { 
check r (rapp (fTm (sFun a r) /) (fTm o s)) => good (sapp / s) 
check r (rapp (fTm (sFun o r) /) (fTm (fDiff a a') s)) *4- bad [] } 

If we use your compare view, we can see directly that the types match in 
one case and mismatch in the other. For the former, we can now return a well 
typed application. The latter is definitely wrong. 

We’ve done all the good cases, and we’re left with choosing inhabitants of 
TErro r F for the bad cases. There’s no reason why you shouldn’t define TErrorT 
to make this as easy as possible. Just pack up the information which is lying 
around! For the case we’ve just seen, you could have: 13 

( a' : Diff a ; / : STm T (sFun cr t) ; s : STm r (fDiff o a') \ 

l mismatchError cr'/ s : TErrorT I 

fTError (mismatchError o' f s) => rapp (fTm ?/) (fTm ? s) 

This recipe gives one constructor for each bad case, and you don’t have any choice 
about its declaration. There are two basic type errors—the above mismatch and 
the application of a non-function. The remaining three bad cases just propagate 
failure outwards: you get a type of located errors. 


The ? means ‘please infer’—it’s often useful when writing forgetful maps. Why? 








Of course, you’ll need to develop comparable first. To define Diff, just play 
the same type-of-diagnostics game. Develop the equality test, much as you would 
with the Boolean version, but using the view recursively in order to see when 
the sources and targets of two sFuns are the same. If you need a hint, see [27]. 

What have we achieved? We’ve written a typechecker which not only returns 
some well typed term or error message, but, specifically, the well typed term 
or error message which corresponds to its input by fTm or fTError. That 
correspondance is directly expressed by a very high level derived form of pattern 
matching: not rvar, rapp or rlda, but ‘well typed’ or ‘ill typed’. 


5.2 A Typesafe and Total Interpreter 

Once you have a well typed term, you can extract some operational benefit from 
its well-typedness—you can execute it without run-time checks. This example 
was inspired by Lennart Augustsson and Magnus Carlsson’s interpreter for terms 
with a typing proof [5]. Epigram’s inductive families allow us a more direct 
approach: we just write down a denotational semantics for well typed terms. 
Firstly, we must interpret SType: 



Value r <t= rec r { 

Value t <= case r { 

Values Nat =>■ Nat 

Value (s Fun <r r) =>■ Value o — > Value r }} 


Now we can explain how to interpret a context by an environment of values: 



Next, interpret variables by looking them up: 



evar jvz <= case 7 { 
evar (ebind 7 v) vz => v } 
evar 7 (vs i ) <*= case 7 { 
evar (ebind 7 v) (vs i) =>■ evar 7 i }}} 


Finally, interpret the well typed terms: 







let 


7 : Env r ; t : STm T r 
eval 7 t : Value r 


eval 7 t <= rec t { 
eval 7 t <= case t { 
eval 7 (svar i) =7 evar 7 1 
eval 7 (sapp / s) => eval 7 / (eval 7 s) 
eval 7 (slda f) =>• Ai> =>eval (ebind 7 v) t }} 


Exercise 25 Make an environment whose entries are the constructors for Nat, 
together with some kind of iterator. Add two and two. 


6 Epilogue 

Well, we’ve learned to add two and two. It’s true that Epigram is currently little 
more than a toy, but must it necessarily remain so? There is much work to do. 

I hope I have shown that precise data structures can manipulated successfully 
and in a highly articulate manner. You don’t have to be content with giving 
orders to the computer and keeping your ideas to yourself. What has become 
practical is a notion of program as effective explanation, rather than merely an 
effective procedure. Upon what does this practicality depend? 

— adapting the programming language to suit dependent types 

Our conventional programming constructs are not well-suited either to cope 
with or to capitalize on the richness of dependent data structures. We have 
had to face up to the fact that inspecting one value can tell us more about 
types and about other values. And so it should: at long last, testing makes a 
difference! Moreover, the ability of types to talk about values gives us ready 
access to a new, more articulate way of programming with the high-level 
structure of values expressed directly as patterns. 

— using type information earlier in the programming process 

With so much structure—and computation—at the type level, keeping your¬ 
self type correct is inevitably more difficult. But it isn’t necessary! Machines 
can check types and run programs, so use them! Interactive programming 
shortens the feedback loop, and it makes types a positive input to the pro¬ 
gramming process, not just a means to police its output. 

— changing the programs we choose to write 

We shouldn’t expect dependently typed programming merely to extend the 
functional canon with new programs which could not be typed before. In 
order to exploit the power of dependent types to express and enforce stronger 
invariants, we need a new style of programming which explicitly establishes 
those invariants. We need to rework old programs, replacing uninformative 
types with informative ones. 



6.1 Related Work 


Epigram’s elder siblings are DML [39] and Cayenne [4]. DML equips ML pro¬ 
grams with types refined by linear integer constraints and equips the typechecker 
with a constraint-solver. Correspondingly, many basic invariants, especially those 
involving sizes and ranges, can be statically enforced—this significantly reduces 
the overhead of run time checking [40]. Epigram has no specialist constraint- 
solver for arithmetic, although such a thing is a possible and useful extension. 
Epigram’s strength is in the diversity of its type-level language. 

Cayenne is much more ambitious than DML and a lot closer to Epigram. 
It’s notorious for its looping typechecker, although (contrary to popular miscon¬ 
ception) this is not an inevitable consequence of mixing dependent types with 
general recursion—recursion is implemented via fixpoints, so even structurally 
recursive programs can loop—you can always expand a fixpoint. 

Cayenne’s main drawback is that it doesn’t support the kind of inductive 
families which Epigram inherited from the Alf system [21,13]. It rules out those 
in which constructors only target parts of a family, the way vnil makes empty 
vectors and vcons makes nonempty vectors. This also rules out SVar, STm and 
all of our ‘views’. All of these examples can be given a cumbersome encoding if 
you are willing to work hard enough: I for one am not. 

The Agda proof assistant [12], like Epigram, is very much in the spirit of 
Alf, but it currently imposes the same restrictions on inductive definitions as 
Cayenne and hence would struggle to support the programs in these notes— 
this unfortunate situation is unlikely to continue. Meanwhile Coq [11] certainly 
accepts the inductive definitions in this paper: it just has no practical support 
for programming with them—there is no good reason for this to remain so. 

In fact, the closest programming language to Epigram at time of writing 
is Haskell, with ghc’s new ‘generalised algebraic data types’ [33]. These turn 
out to be, more or less, inductive families! Of course, in order to preserve the 
rigid separation of static types and dynamic terms, GADTs must be indexed 
by type expressions. It becomes quite easy to express examples like the type- 
safe interpreter, which exploit the invariants enforced by indexing. What is still 
far from obvious is how to establish invariants for run time data, as we did 
in our typechecker—this requires precisely the transfer of information from the 
dynamic to the static which is still excluded. 


6.2 What is to be done? 

We have only the very basic apparatus of dependently typed programming in 
place at the moment. We certainly need some way to analyse the results of inter¬ 
mediate computations in a way which reflects their significance for the existing 
type and value information—I have studiously avoided this issue in these notes. 
In [27], we propose a construct which adds the result of an intermediate compu¬ 
tation to the collection of values being scrutinized on the left-hand side, at the 
same time abstracting it from types. This is not yet implemented. 


We shall certainly need coinductive data in order to develop interactive sys¬ 
tems. Inspired by the success of monads in Haskell, we shall also need to in¬ 
vestigate the enhanced potential for ‘categorical packaging’ of programming in 
a language where the notion of category can be made abstract. And of course, 
there are all the ‘modern conveniences’: infix operators, ad-hoc polymorphism, 
generics, and so forth. These require design effort: the underlying expressivity is 
available, but we need good choices for their high-level presentation. 

Work has already begun on a compiler for Epigram [10]: we have barely 
started to exploit our new wealth of static information for performance. We have 
the benefit of a large total fragment, in which evaluation strategy is unimportant 
and program transformation is no longer troubled by _L. The fact that partial 
evaluation is already a fact of life for us must surely help also. 

We need a library, but it’s not enough to import the standard presentation 
of standard functionality. Our library must support the idioms of dependently 
typed programming, which may well be different. Standardizing too early might 
be a mistake: we need to explore the design space for standard equipment. 

But the greatest potential for change is in the tools of program development. 
Here, we have barely started. Refinement-style editing is great when you have a 
plan, but often we don’t. We need to develop refactoring technology for Epigram, 
so that we can sharpen our definitions as we learn from experiments. It’s seldom 
straight away that we happen upon exactly the indexed data structure we need. 

Moreover, we need editing facilities that reflect the idioms of programming. 
Many data structures have a rationale behind them—they are intended to relate 
to other data structures in particular ways and support particular operations. At 
the moment we write none of this down. The well typed terms are supposed to be 
a more carefully indexed version of the raw terms—we should have been able to 
construct them explicitly as such. If only we could express our design principles 
then we could follow them deliberately. Currently, we engineer coincidences, 
dreaming up datatypes and operations as if from thin air. 

But isn’t this just wishful thinking? I claim not. Dependent types, seen 
through the Curry-Howard lens, can characterize types and programs in a way 
which editing technology can exploit. We’ve already seen one class of logical prin¬ 
ciple reified as a programming operation—the -t= construct. We’ve been applying 
reasoning to the construction of programs on paper for years. We now have what 
we need to do the same effectively on a computer: a high-level programming lan¬ 
guage in which reasons and programs not merely coexist but coincide. 
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